Traditionally, network application access to network services and devices during application development is obtained by way of a software developer kit. As should be understood, the kit is generally distributed by the network operating system software vendor, and typically provides functional interfaces to a network Application Programmers Interface (API). The network API provides access to each of the network services, and also provides mechanisms to create communication channels to other network devices.
Network operating systems services include but are not limited to services provided by application servers, file servers, print servers and other network management tools. Typical management operations include user account management services, file and directory management services, volume services, queuing services, print management services, and connection information services, among other things.
File management services include opening, reading from, writing to, closing, archiving, protecting, encrypting, and otherwise managing files in a multiple user environment. Print management services include generating and maintaining printer definitions, form definitions, print service definitions, and queue connection definitions; pre- and post-filter processing; and print job redirection, among other things. Such services are typically divided into working segments to allow applications to access the services in a functional manner.
For an application to access a requested service, service-related information must be retrieved from a network database, and the retrieved information is employed to access one or more network devices that provides the requested service. Such information includes all the descriptive information about each service and identifiers for addressing the network devices and services directly. However, and as should be understood, such a process is cumbersome in that the retrieval of the information and the accessing of the service require multiple requests from the application, and in that the requests must be passed through circuitous routes.
A need exists, then, for a system and method for encapsulating network service-related information and network devices such that an application can virtually communicate directly with the appropriate network device or devices that provides the requested service. As should be understood, virtual communication refers to a logical communication process rather than a physically communication process.
Virtual communication between network-attached devices is made possible by creating channels, ports, or "sockets", where each socket defines a logical connection between a first device and a second device. As should be understood by one skilled in the art, first and second devices connected by a socket can only communicate with each other by / through the socket. The same description holds true for software tasks which are communicating with each other through the network media. Tasks connected on a socket are guaranteed to send signals or messages to each other.
Messages are streams of data which are packetized in such a way that the message ends up at the right destination task and each end of the socket can decipher the information or data which is trying to be communicated. The packetized information contains identifiers and indexes which may change the state of the communication channel.
As one skilled in the art should recognize, object-oriented analysis and design (OOA&D) is an approach for classifying and describing interactions between object components, and then encapsulating and modeling such object components. Classifications are defined by generalizing object components. Object components are identified by recognizing characterizations and functions which behave as individual entities and have unique behavior and descriptive attributes. In the invention to be described below, a set of classifications, object components, and interactions between object components are defined. As seen in the drawings, the OOA&D for the present invention may be fully described though the use of classification and object component diagrams.
OOA&D object technology, object analysis, design theory, and terminology is discussed in detail in Object-Oriented Analysis and Design with Applications, Grady Booch, [Redwood City, Calif.: Benjamin/Cummings, 1993], hereby incorporated by reference. Because object designs build on each other (i.e. new objects are generally built from older objects), several class libraries are available for starting a new analysis and design. The object design of the present invention builds on the Rogue Wave Foundation Class Libraries, TOOLS.H++. As should be understood, TOOLS.H++ has classifications for objects such as strings, multi-byte strings, localized time and date, hash sets, binary trees, dictionaries, sorted lists, linked lists, etc.
The model-view-controller (MVC) architecture is a useful architectures used by OOA&D applications. The MVC is essentially a trinity of objects and classifications which facilitates the physical data collection (model), the expression or composition of the data presentation (view), and the interaction or interface between the presentation and the user or outside influence (controller).
Models are the physical data collection or content of the physical devices and the behavior or the devices as described by the system make up the objects. Each model keeps track of the raw data which may or may not be understandable to the user or outside influence. Views are the objects which interact directly with the models and whose primary purpose is to shape or present the model raw data. Each model may contain several view instances and each view may only exist for one model.
Each view instance may present the model in different ways or may only present sections or subsections or information about the model. The view can also write information into the model as raw data. In the implementation of the MVC, raw information is periodically collected by the model if at least one view exists for such model. A reference is registered with a model for every view created for the model. When a view is destroyed, the respective reference is released by the respective model.
The models and views are manipulated and processed with the actions of controller objects (also referred to as user interface objects). The controller objects cause methods of a view to be invoked which in turn may cause reactions in a related model. Accordingly, controller objects tend to cause the MVC architecture to be highly event-driven. Therefore, event-driven operating systems such as the MICROSOFT WINDOWS operating system from MICROSOFT Corporation allow for a clean existence of an MVC architecture.